Skip to content

fix(vks): --secondary-subnets takes CIDRs, not subnet IDs#44

Open
vks-team wants to merge 1 commit into
mainfrom
fix/secondary-subnets-cidr
Open

fix(vks): --secondary-subnets takes CIDRs, not subnet IDs#44
vks-team wants to merge 1 commit into
mainfrom
fix/secondary-subnets-cidr

Conversation

@vks-team

Copy link
Copy Markdown
Contributor

Root cause

The VKS API field secondarySubnets expects CIDR strings (address ranges, e.g. 10.5.60.0/22) — the spec example is ["10.200.27.0/24", "10.200.28.0/24"]. But the CLI's --secondary-subnets help text and the create-cluster docs described them as "Secondary subnet IDs" and used sub-… examples.

This mislabeling was reinforced in #42. Anyone (or any agent) following the guidance builds a request body the backend rejects. The parallel bug in greennode-mcp (SubnetItem extracting sec-sub-* uuids, guides/docstrings saying "Secondary subnet IDs") was fixed separately.

Changes

  • create_cluster.go: --secondary-subnets help now reads "Secondary subnet CIDRs, comma-separated, e.g. 10.5.60.0/22 … NOT subnet IDs".
  • docs/commands/vks/create-cluster.md: option description clarified (CIDRs, not sec-sub-… IDs), syntax + both examples use CIDR strings.

Behavior is unchanged — the CLI forwards the value verbatim; only the guidance was wrong.

Verify

go vet, CGO_ENABLED=0 go build, and --help output confirmed.

The API field secondarySubnets expects address ranges (e.g. 10.5.60.0/22),
but the help text and docs said "Secondary subnet IDs" and used sub-*/sec-sub-*
examples. An agent or user following that guidance builds a body the backend
rejects. Correct the flag help, the option description, and both examples to
CIDR strings. Behavior is unchanged (the value is forwarded verbatim).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant